Field of the Invention
The present invention relates generally to graphical programming and visual software development and, more specifically, to building solutions integrating disparate software systems without programming.
Description of the Related Art
In 1968, Doug McIlroy, a noted computer scientist, wrote: “Follow the lead of hardware design! It is not right that every new development should start from scratch. There should be catalogs of software modules, as there are catalogs of VLSI devices: when we build a new system, we should be ordering components from these catalogs and combining them, rather than reinventing the wheel every time. We would write less software, and perhaps do a better job at which we do get to write.”
Creating software is generally known to be technically challenging, time consuming, and expensive. Enterprise software products and solutions can have thousands of objects and source code modules. Electronic circuit design can be equally challenging. Central processing units (CPUs) may contain millions of microscopic devices. Electronic design has been greatly simplified by assembling pre-existing components using Computer Aided Design (CAD) software.
Software packages for graphical electronic design are widely commercially available. Such a package may include various windows and browsers in which elements of the package are operated. One such element may provide a hierarchical view of components used in the solution. This can include their identity, and containment relationships. Another such element can provide a graphical view of the solution under design, illustrating the physical layout of components and the logical arrangement of an algorithm as expressed as data and control flow between components. Another element can provide a display of a currently selected component's attributes. There can also be a toolbox that provides a display of available components that can be placed on the design surface as part of the circuit assembly process. Using these elements, a circuit designer can graphically select components, place them in any desired arrangement and interconnect them to define a design. Software packages that include electronic CAD features may also compile the design and output a netlist. A netlist describes the connectivity of an electronic design and is used during the fabrication of integrated circuits. With modern circuits having millions of microscopic components, utilizing an electronic CAD package during design has become mandatory.
Software tools are becoming more and more similar to the CAD tools used in circuit design. The Integrated Development Environment (IDE) has become the standard foundation for modern Rapid Application Development (RAD) tools, and is remarkably similar to electronic CAD tools. Examples of software IDEs include Borland Software Corporation's DELPHI® and JBUILDER®, Sybase Inc.'s POWERBUILDER®, Microsoft Corporation's VISUAL BASIC® and MICROSOFT VISUAL STUDIO®, IBM Corporation's VISUAL AID®, and many others.
As illustrated in FIG. 2 Microsoft's VISUAL STUDIO® IDE includes a number of graphical elements. The Design Surface 201 is where objects can be assembled into a new software application, library, or service. The Solution Explorer 202 is a hierarchical explorer of the objects and software deliverables that comprise the solution. The Toolbox 203 contains a catalog of reusable objects that can be dragged onto a design surface to facilitate the assembly. The Property Grid 204 that shows and allows the manipulation of the property values of the currently selected object. The Source Code 205 editor for programmers to write source code, and may also show the source code that is generated in response to user manipulation of the properties of objects with the property grid, and the placing of additional objects from the toolbox onto a design surface. A Compiler consumes the source code created within the environment, both by programmers and generated by the IDE, in order to produce the modules that comprise a new software program.
The typical IDEs' graphical designers are usually limited to the creation of the Graphical User Interface (GUI). Unlike Electronic CAD, typical IDEs require programmers to author source code to define the software's algorithms.
More recent IDEs have included the ability to define integration and logic algorithms graphically in a manner similar to Electronic CAD. Known as “Visual Programming”, these tools use a graphical diagram where nodes are visually connected. The nodes may represent a variable, a function, an object, or an operator. These tools may generate source code that is compiled, or a script that is interpreted. Visual Programming is known to greatly reduce the time and complexity of software construction. National Instruments Corporation's LABVIEW® is an example of a well-known Visual Programming environment utilized in the instrumentation and measurement market.
Application Integration tools enable the construction of new software solutions that integrate existing software systems. These tools are known to use Connectors, also known as Drivers or Adapters, to provide software routines for intelligent interaction with existing software systems. Connectors provide a common Application Program Interface (API) that maps to an existing system's “Open” APIs. Open is the term generally used to mean “for public use.” For this definition, API may include a software system's data stores. Open APIs may be software system specific, such as for Siebel or Clarify, CRM vendors with rich software development kits. Open APIs may also be standards, such as Open Database Connectivity (ODBC). In this manner, programmers can master the common API, and use Connectors to interact with multiple APIs without needing to master the interface details of the APIs.
When a software system does not provide an Open API, a Connector can be difficult or impossible to build. These software systems are called “closed.” Many times, legacy software systems, especially those built by a business' internal staff, are closed. The large number of closed software systems is well known to be the most significant issue confronting software integration. As a result, while many major software systems have Connectors, most software systems do not. iWay Software, a well known provider of Connectors to commercial software systems, has less than 300 Connectors as of this writing. This is just a tiny fraction of software systems in existence.
When a family of software systems or hardware devices exist that provide common functionality but are manufactured by multiple vendors, standard APIs are defined, typically by a major vendor or a consortium of vendors. Connectors built to a standard API meant to be used by a plurality of parties, rather than an API to a specific software system, are typically called Drivers. For example, Microsoft has defined numerous API standards for their Windows operating system to drive hardware devices such as video cards. The IVI Foundation has defined the Interchangeable Virtual Instruments API standards for the measurement and instrumentation industry for driving a variety of hardware devices, such as for data acquisition. IVI drivers are one of the standards National Instruments uses for integration to hardware devices in their Visual Programming tool, LABVIEW®. Database vendors typically provide a specific connector to their database software, as well as an ODBC Driver using the well known ODBC standard mentioned above.
Drivers have been historically limited to provide the necessary abstraction to make the most common computing tasks possible, such as accessing a database or rendering graphics on a computer's display. The effort required to create a suitable standard that has a chance of industry adoption is high. Programmers compete by creating new software systems with proprietary and differentiating functionality where standards are impossible to define, even for two software systems which aim to solve the same problem. As a result, Drivers exist for a small number of very narrow domains.
A more recent form of Connector is one where a user interface is provided for interrogating a software system's Open APIs to construct a new API in a preferred form. This type of Connector is typically called an Adapter. iWay Software allows for Adapters to be constructed that may combine many elements of a complex software system, such SAP or Clarify, to produce a Java or Web Service API. This not only shields programmers from the technical details of the target systems APIs, but allows them to dynamically define the new API customized to their needs. This eliminates the common problem of standards that become out of date.
While Adapters overcome some of the issues with Connectors or Drivers, the production of a programmatic API limits its use to programmers with tools compatible with the software platforms an Adapter chooses to support. Additionally, Adapters of the prior art are limited to Open APIs, and therefore do not overcome the issue of the majority of software systems that are closed.
Visual Programming tools of the prior art have significant limitations in their ability to integrate with existing software systems. They are known to support graphical nodes that expose Drivers, and as a result the Visual Programming tools of the prior art have been limited to very narrow domains where compatible Drivers have been constructed.
Additionally, a Visual Programming environment may be able to dynamically integrate to existing software systems when the software system offers a programmatic interface compatible with the Visual Programming environment, such as a tool developed for the MICROSOFT WINDOWS® platform may be able to integrate with a software program that offers a COM API. Not only does this require knowledge of programmatic interfaces beyond that of many users, it limits the available software programs to those that offer a compatible programmatic interface. The number of software programs that offer incompatible programmatic interfaces is far greater than those that do, and therefore strictly limits the number of available compatible programs.
A Visual Programming tool may use an Adapter that provides a compatible programmatic interface, but this would not overcome the limitations Adapters impose on integration with open systems.
Due to these limitations, Visual Programming tools of the prior art have been limited to small exclusive domains where extensive concerted efforts have been made to create a catalog of reusable components. The majority of new software solutions are therefore still manually created by programmers at great expense, time, and risk. The present invention addresses these problems and deficiencies and others in the manner described below.